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ABSTRACT 

The Systems Development Branch (SDB) at NASA 
Langley Research Center (LaRC) creates simulation 
software products for research. Qach product consists 
of an aircraft model with experiment extensions. SDB 
treats its aircraft models as reusable components, upon 
which experiments can be built. SDB has evolved its 
aircraft model design with the following goals: 

1 . Avoid polluting the aircraft model with experiment 
code. 

2. Discourage the “copy and tailor” method of reuse. 
The current evolution of that architecture accomplishes 
these goals by reducing experiment creation to “extend 
and compose”. The architecture mechanizes the opera- 
tional concerns of the model’s subsystems and encapsu- 
lates them in an interface inherited by all subsystems. 
Generic operational code exercises the subsystems 
through the shared interface. An experiment is thus 
defined by the collection of subsystems that it creates 
(“compose”). Teams can modify the aircraft subsys- 
tems for the experiment using inheritance and polymor- 
phism to create variants (“extend”). 
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INTRODUCTION 

SDB defines a project for each experiment (e.g. set of 
requirements) and assigns a team (e.g. a group of devel- 
opers) to the project. “Project” is used frequently in 
place of “experiment” or “team” to differentiate from 
the requirements and the team for the aircraft model. 

At a basic level, developing a simulation experiment 
involves adding, modifying, and/or subtracting behav- 
iors to a known aircraft model. When LaRC used a 
procedural design paradigm to produce simulation 
products, projects employed the following methods to 
make some of the experiment modifications: 

1. Adding conditional constructs to the “baseline” 1 ^ 
aircraft code. These constructs can be control 
statements (e.g. if-then-else) or pre-processor 
guards. 

2. Tailor the aircraft code for the experiment. 

The problem with conditional constructs is that they 
pollute the aircraft model with experiment code. Each 
simulation experiment inherits code for other simulation 
experiments. Defects could be introduced that acciden- 
tally activate the code from another experiment. Code 
size and complexity also increases over time. This 
slows maintenance and heightens the opportunity for 
defects. The issue with ’’copy and tailor” ^ reuse is in- 
creased configuration management complexity. Devel- 

^ “Baseline aircraft code” is an approved version of the 
code, with which all projects start. 

* Based on the configuration management tool that 
LaRC used at the time, a more accurate statement would 
be “retrieve and modify”. The tool retrieved the base- 
line file and applied a modification file to it that re- 
sulted in the tailored file. 
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Figure 1 Aircraft Decomposition in LaSRS++ 


opers may have to reconcile conflicts between project 
changes and updates to the aircraft code. If a project 
creates a desirable feature (i.e., a feature that other pro- 
jects want included in the AircraftModel), extracting 
that feature from the other project modifications could 
take considerable effort and testing. 

When LaRC re-engineered the simulation framework to 
object-oriented technology, the architecture had a goal 
to avoid the need to copy aircraft code or to pollute it 
with project-specific items. This paper describes the 
current evolution of that architecture. The discussion 
employs the following conventions to keep text concise. 
“ClassName object” designates an object created from 
ClassName or its descendents. “ ClassName derivative” 
indicates any class descended from ClassName. 
Method names that appear in italics are abstract inter- 
faces that must be defined by descendent classes. 
Method names that appear in bold are concrete defini- 
tions of an abstract interface. The diagrams use the 
Unified Modeling Language (UML) notation. 1 


AIRCRAFT DECOMPOSITION 

SDB builds all of its simulation products using an ob- 
ject-oriented framework called the Langley Standard 
Real-Time Simulation in C++ (LaSRS++). 2 * All aircraft 
models derive from classes within LaSRS++. Figure 1 
illustrates the structure of LaSRS++ aircraft 5 . 0 An air- 
craft model is composed of three major parts: 

1. Subsystem models descended from Simulation- 
Model. Aerodynamic models and engine models 
are examples of subsystem models. 

2. Mediator classes descended from Vehicle System. 
Vehicle Systems follow the mediator design pattern 
to decouple subsystem models from other parts of 
the aircraft. 3,4 Vehicle Systems construct the sub- 
system model and handle I/O for the subsystem 
model. Cunningham covers the relationship be- 
tween VehicleSystem derivatives and subsystem 
models in more detail. 4 In figure 1, B757Aero- 

§ The figure is a simplified representation of the archi- 
tecture for the purposes of discussion. Some intermedi- 
ate classes and some relationships are not shown. 
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System descends from VehicleSystem. It creates 
the B757AeroModel object. It retrieves, from vari- 
ous sources, the inputs to B757AeroModel. It 
feeds these inputs into the B757AeroModel object 
and executes the model. Lastly, the B757 Aero- 
System makes the model’s outputs available to ob- 
jects (e.g. other VehicleSystems). 

3. The composite class descended from Vehicle. This 
paper will refer to the composite class as Aircraft- 
Model. The AircraftModel represents the entire 
aircraft. AircraftModel aggregates the VehicleSys- 
tem objects that, in combination, model the given 
aircraft. This paper covers the evolution of the re- 
lationship between Vehicle objects and VehicleSys- 
tem objects that enable verbatim reuse of Aircraft- 
Model while maintaining separation between air- 
craft code and experiment logic. In figure 1, Boe- 
ing757 is the AircraftModel. 

When a project extends the aircraft model for an ex- 
periment, the project begins by deriving a class from the 
AircraftModel. This paper will refer to the derived 
class as the ProjectModel. The ProjectModel starts 
with the default composition of VehicleSystem objects 
defined by the AircraftModel. The ProjectModel can 
then modify this composition as required for the ex- 
periment. The ProjectModel has three basic options to 
change the composition: add, replace, or subtract Vehi- 
cleSystem objects. 

Figure 1 uses a fictitious project, the Porous Airfoil 
Demonstrator (PAD). PAD will evaluate the effects of 
adding passive porosity to a Boeing 757. PAD has 
modeled porosity effects as increments to the aerody- 
namic coefficients. The project team begins by deriving 
a B757PadAeroModel class from B757AeroModel. 
B757PadAeroModel inherits the aerodynamic proper- 
ties of an unmodified Boeing 757. The class then adds 
the computations for modeling porosity and sums the 
increments with the basic Boeing 757 coefficients. The 
team next creates the B757Pad and B757PadAeroSys- 
tem classes. B757Pad represents the tailored aircraft 
model. It modifies the Boeing757 model by replacing 
the default B757AeroSystem with the B757PadAero- 
System. B757PadAeroSystem creates the B757Pad- 
AeroModel. B757PadAeroSystem derives from B757- 
AeroSystem because the class reuses all of the logic 


from B757AeroSystem that feeds inputs into the base 
class portion of B757PadAeroModel, i.e. B757Aero- 
Model. Yet, B757PadAeroSystem must provide any 
additional inputs for the passive porosity model. 
B757PadAeroSystem may provide additional outputs if 
the porosity increments to aerodynamic coefficients are 
required elsewhere 11 . 

The example shows that the LaSRS++ architecture uses 
inheritance to reuse and extend behavior in all three 
major subdivisions of an aircraft model: the vehicle, the 
vehicle system, and the subsystem model. Inheritance 
acts as a substitute for conditional statements that were 
used in the procedural paradigm. Inheritance leaves the 
AircraftModel code unchanged. All code additions for 
the experiment are isolated in the derived classes. Ex- 
periment code is incorporated into the product only if 
the derived classes are linked into the product. 

GENERALIZING AIRCRAFT BEHAVIOR 

The aircraft decomposition in LaSRS++ is not sufficient 
to avoid copy and tailor. In earlier LaSRS++ designs, 
the AircraftModel and ProjectModel were responsible 
for operating their composition of VehicleSystem ob- 
jects. The AircraftModel would contain the logic for 
operating the default composition of VehicleSystem 
objects. The ProjectModel, in changing the composi- 
tion of VehicleSystem objects, would have to provide 
modified operational logic. In these earlier designs, 
projects overrode the AircraftModel logic with a tai- 
lored copy that was placed in the ProjectModel. Thus, 
the ’’copy and tailor” method of reuse crept into the 
normal process of creating ProjectModels. 

Removing ’’copy and tailor” from the process of creat- 
ing ProjectModels required architectural enhancements 
to the current decomposition. The early projects were 
examined for emerging patterns of VehicleSystem op- 
eration # Give basic actions were identified: 


11 Many LaSRS++ designers choose to make the outputs 
available by providing a constant reference to the 
underlying model. In this example, 

B757PadAeroSystem would provide a constant refer- 
ence to B757Pad-AeroModel. 

# Initialization actions were also identified and mecha- 
nized. Initialization is not covered due to lack of space 


3 

American Institute of Aeronautics and Astronautics 




Figure 2 Detailed Vehicle- VehicleSystem Design 


• The operational code must execute the VehicleSys- 
tem objects in the correct order. 

• The operational code must call the update method 
defined by each VehicleSystem object. 

• The operational code must execute each Vehicle- 
System object under the correct circumstances. 
LaSRS++ has different modes of execution (e.g. 
RESET, HOLD, OPERATE). It may be incorrect 
for a VehicleSystem to update in each mode. For 
example, does the object execute in RESET mode 
as well as OPERATE mode? 

• The operational code must link VehicleSystem ob- 
jects to the correct input sources. As stated earlier, 
VehicleSystem objects act as mediators for a com- 
panion subsystem model. 

• The operational code must acquire VehicleSystem 
outputs that affect behavior of the vehicle. 

The first three actions can be categorized as execution, 

the fourth deals with inputs, and the last deals with out- 


and because the mechanisms are similar to those de- 
scribed for operation. 


puts. The design enhancements captured these actions 
as new abstractions, i.e. new attributes and operations in 
the VehicleSystem and Vehicle classes. The purpose of 
the new abstractions was the development of generic, 
reusable operation code that could be pushed into the 
LaSRS++ framework. Developers would no longer 
create operational code in the AircraftModel and Pro- 
jectModel classes. The primary responsibilities of Air- 
craftModel and ProjectModel would reduce to defining 
the VehicleSystem composition. The new design would 
remove the need to "copy and tailor" while simplifying 
the work in creating new ProjectModels. 

Figure 2 illustrates the new design. The Vehicle base 
class manages a list of the VehicleSystem objects that 
define the model. This list is named the system_list. 
Vehicle contains methods that manipulate its sys- 
tem list and that execute behaviors for all items on the 
list. These methods are identified and described in the 
sections that follow. Vehicle also contains generic op- 
erational code for operating the Vehicle Systems in the 
various simulation modes. These methods begin with 
the prefix ‘do’, e.g. doResetCalcQ. VehicleSystem con- 
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tains an abstract interface for the services that are re- 
quired by the generic operational code in Vehicle. The 
next five sections look at how the design addresses each 
of operational actions. 

Order of Execution (Execution) 

The order in which Vehicle System objects execute is 
important. Some VehicleSystem objects provide inputs 
to other VehicleSystem objects. For example, the 
B757AeroSystem requires control surface inputs for the 
B757AeroModel. The control surface inputs are com- 
puted when B757ControlSystem is executed. In 
LaSRS++, the B757ControlSystem must execute before 
the B757AeroModel. The Vehicle class equates order 
of execution with order of registration. When the Ve- 
hicle object constructs each VehicleSystem object, the 
Vehicle object registers the VehicleSystem object using 
Vehicle: :registerVehicleSystem(). This method adds 
the VehicleSystem object to the end of system_list. The 
Vehicle object will execute the VehicleSystem objects 
in the order on the system_list. 

The registerVehicleSystem() calls made by the Air- 
craftModel class represent the default execution order 
for all variations of that aircraft. The Vehicle class pro- 
vides methods that allow the ProjectModel to change 
the default registration order. If the ProjectModel 
wants to replace a VehicleSystem object created by the 
AircraftModel, it calls Vehicle :: replace Vehicle- 

System(). In the example, B757Pad would call Vehi- 
cle ::replaceVehicleSystem() to replace the B757 Aero- 
System created by its parent, Boeing757, with 
B757PadAeroSystem. B757PadAeroSystem will now 
be executed at the same position in the system_list that 
was occupied by B757AeroSystem. 

If the ProjectModel needs to reorder the list, then the 
ProjectModel can call Vehicle:: clearVehicle System- 
List() to empty the list and call Vehicle: :registerVe- 
hicleSystem() to add VehicleSystem objects back onto 
the list in the desired order. Being a child of the Air- 
craftModel, the ProjectModel has access to all of the 
VehicleSystem objects created by the AircraftModel. 
Therefore, it can combine the AircraftModel’ s Vehicle- 
System objects with its own VehicleSystem objects 
when it reorders the list. 


Invoke the Correct Behavior (Execution) 

Each VehicleSystem object has unique behaviors. But, 
in simple terms, they perform the same action: populate 
the subsystem model inputs and execute the subsystem 
model. Thus, the same meaningful name can be used to 
describe the action for all VehicleSystem objects. The 
design defines an abstract method for invoking the ac- 
tion, VehicleSystem: :update() . Each VehicleSystem 
derivative defines that method to execute its own unique 
behaviors. This object-oriented mechanism is called 
polymorphism. When the client code calls the update() 
method, the actions that are actually taken depend on 
the object upon which the method is invoked. This al- 
lows generic code to invoke the same action on a col- 
lection of objects through its common ancestor but al- 
lows each object to uniquely respond. The Vehicle’s 
generic code does not directly call this method, but it 
plays an important role in abstracting “Operational 
Situations” described next. 

Operational Situations (Execution) 

LaSRS++ has several operational modes. Within each 
of these modes, there may be different points, at which 
VehicleSystems are run. These points are called “op- 
erational situations” in this paper. The VehicleSystem 
design captures these operational situations in the enu- 
meration VehicleSystem: :UpdateSituation. The opera- 
tional situations for LaSRS++ are defined in Table 1. 

The VehicleSystem object defines the operational situa- 
tions in which it runs by calling VehicleSystem: :set- 
UpdateSituation(). When each operational situation is 
encountered, the generic operational code in Vehicle 
calls the callUpdateNow() method on every registered 
VehicleSystem object. The code passes an Update- 
Situation value as an argument to VehicleSystem: :call- 
UpdateNow(). Each VehicleSystem object compares 
the situation against those it has defined. If there is not 
a match, the VehicleSystem object returns without tak- 
ing an action. If there is a match, the object runs the 
abstract update() method. This is where the polymor- 
phic VehicleSystem: :update() plays its role. Vehicle- 
System: :callUpdateNow() is generic, non-polymorphic 
code because it relies on the abstract interface Vehicle- 
System: :update() to execute the behavior appropriate to 
the object. 
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Table 1: Operational Situations 

Operational Situations 

Description 

DORESET 

RESET mode after the scenario has been defined 

DOTRIM 

TRIM mode after the equilibrium computation for the frame is complete 

DOHOLD 

HOLD mode 

DOOPERATEFORCE 

The force computation in OPERATE mode 

DOOPERATELAST 

After the acceleration computation in OPERATE mode 

DOPROPAGATESTATE 

After the integration of the Vehicle states while in OPERATE mode. 

VEHICLE EOM F ORCE 

During the force computation when in the equilibrium computation of TRIM 
mode or the derivative computation of LINEARMODEL mode. 

VEHICLEEOMLAST 

After the acceleration computation when in the equilibrium computation of TRIM 
mode or the derivative computation of LINEAR MODEL mode. 


If a ProjectModel wants to add or subtract an opera- 
tional situation for a Vehicle System object, it calls Ve- 
hicleSystem::setUpdateSituation(). This method takes 
two arguments, an UpdateSituation value and a Boolean 
that adds the situation when true and subtracts it when 
false. 

In the example, B757AeroSystem sets the following 
operational situations on itself: DO_OPERATE_ 

FORCE and VEHICLEEOMF ORCE . When the 

simulation is running in OPERATE mode, Vehicle: :do- 
Operate() first computes the external forces and mo- 
ments on the vehicle. It calls updateSystems(DO_OP- 
ERATE_FORCE). This method, in turn, calls callUp- 
dateNow(DOOPERATEFORCE) on every Vehicle- 
System object. The B757AeroSystem will respond by 
executing B757AeroModel. Before Vehicle: :doOp- 
erate() exits, it will call updateSystems(DO_OP- 
ERATE_LAST). B 75 7 Aero System will respond by 

performing no actions because it has not defined DO_ 
OPERATE_LAST as an operational situation for itself. 

One weakness to this design is that it assumes the same 
execution order holds for all operational situations. 
This has been true for all of the AircraftModels and 
ProjectModels that SDB has created. If an aircraft or a 
project must use a different execution orders for each 
operational situation, the operational methods (doRe- 
set(), doOperateCalc(), etc.) remain virtual so that their 
behaviors can be overridden by an AircraftModel or 
ProjectModel. The VehicleSystem design could be 
enhanced to add different execution orders for different 
operational situations. But, SDB decided that the addi- 


tional complexity was unwarranted for a feature that 
might never be exercised. 

Establishing Communications (Input) 

The major role of the VehicleSystem object is as an 
agent for the SimulationModel object that handles the 
SimulationModel object’s I/O. The VehicleSystem 
object knows the source of each input to the Simula- 
tionModel object. It feeds those inputs into the Simula- 
tionModel object and then executes the model. This 
keeps the SimulationModel class decoupled from other 
parts of the ProjectModel. The SimulationModel class 
can more easily be unit tested in isolation and can be 
reused in other ProjectModels. 4 

The VehicleSystem object must build connections to 
those input sources. The connection usually takes the 
form of a pointer or reference to the source. Such links 
could be established by passing the source reference as 
an argument to the VehicleSystem derivative’s 
constructor. However, all sources of a VehicleSystem 
object must be constructed prior to the VehicleSystem 
object for the references to be valid. The result imposes 
a construction order based on association. It also as- 
sumes that there is a possible construction order, in 
which all input sources for each VehicleSystem object 
will be valid. This is not the case when VehicleSystem 
objects associate bidirectionally or when a circular as- 
sociation exists among a collection of VehicleSystem 
objects. For example, B757AeroSystem receives inputs 
from B757ControlSystem; and B757ControlSystem 
receives inputs from B757AeroSystem. To accommo- 
date all possible association patterns, establishing com- 
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Figure 3 Establishing and Rewiring Connections 

munication must be broken out as a distinct behavior 
from composition. 

The VehicleSystem class provides the abstract method 
setLinks() for this purpose. The VehicleSystem deriva- 
tive defines setLinks() to establish the connections to 
other VehicleSystem objects that provide the input data 
for its companion model. The AircraftM odel and Pro- 
jectModel objects maintain accessors*" tq 


each Vehi- 


cleSystem object they create. The concrete setLinks() 
calls these accessors to obtain the required sources. 
The Vehicle class provides the linkSystems() method to 
invoke setLinks() on each object that appears on the 
systemlist. 


An accessor is a method that returns a class attribute. 
In this case, the accessor is returning a pointer or refer- 
ence to a VehicleSystem object contained by the class. 


For example, the B757AeroModel needs the con- 
trol surface deflections to compute the aerody- 
namic forces. The control surface deflections are 
stored in B757ControlSystem. The Boeing757 
constructs both the B757ControlSystem and 
B757AeroSystem. After it has registered the 
systems, it calls Vehicle ::linkSystems(), which 
calls setLinks() for each system on its list. 
B757AeroSystem::setLinks() calls Boeing757:: 
getControlSystem() to obtain and store a refer- 
ence to the B757ControlSystem. B757AeroSys- 
tem will use this reference in its update() method 
to retrieve the control surface deflections and 
insert them into the B 75 7 Aero-Model object. 

The design can also handle any necessary “rewir- 
ing” when the ProjectModel replaces a Vehicle- 
System object inherited from the AircraftModel. 
Figure 3 provides an example. Suppose a project 
creates an extended control system to replace the 
B757ControlSystem. This ProjectControlSystem 
would derive from B757ControlSystem. The 
Boeing757 class constructor will connect the 
B757AeroSystem to the B757ControlSystem. In 
replacing B757ControlSystem, the ProjectModel 
will want B 757 AeroSy stem to receive its inputs 
from the ProjectControlSystem. Under early 
LaSRS++ designs, the ProjectModel would con- 
tain code that replaces the value of B757AeroSystem’s 
pointer to the B757ControlSystem with the address of 
the ProjectControlSystem. Under the new design, Air- 
craftModel allows the ProjectModel to replace the val- 
ues of its VehicleSystem pointers with the address of 
project objects. The ProjectModel constructor would 
call Boeing7 5 7 : :pu t B7 5 7 Con t rolSys t e m (&Proj ectCon- 


trolSystcm). Then Bocing7 57:: gctB7 5 7ControlSys- 

tem() would return the address of ProjectControlSys- 
tem. How the implementation accomplishes the rewir- 
ing is more complex than this call. The ProjectModel 
constructor starts by calling the Boeing757 constructor. 
The Boeing757 constructor creates and registers the 
B757ControlSystem and B75 7 AeroSy stem objects. 
The constructor then calls Vehicle ::linkSystems(), 
which invokes B757AeroSystem::setLinks(). B757- 
AeroSystem: : setLinks() calls B oeing7 57:: getB 757- 
ControlSystemQ, which returns the address of the 
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B757ControlSystem object. This is not the desired re- 
sult. However, control is later returned to the Project- 
Model constructor. The ProjectModel constructor cre- 
ates the ProjectControlSystem object. It calls Vehi- 
cle: :replaceVehicleSystem() to replace the B757- 
ControlSystem with the ProjectControlSystem. It also 
calls Boeing757::putB757ControlSystem() to replace 
the address of the B757ControlSystem object with the 
address of the ProjectControlSystem object. Then, the 
constructor calls Vehicle ::linkSystems(). B757Aero- 
System::setLinks() will be re-invoked. When Boe- 
ing757::getB757ControlSystem() is called this time, the 
address of ProjectControlSystem is returned. The nec- 
essary rewiring is done. In other words, the calling the 
ProjectModel constructor results in two passes of Vehi- 
cle: :linkSystems(). The first pass sets up links as de- 
fined by the AircraftModel. The second pass allows the 
project to redefine the links. 


Influencing Vehicle Behavior (Output) 

A large amount of data interaction can occur in an air- 
craft model. As explained in the prior section, the Ve- 
hicleSystem handles the interactions between subsys- 
tems. Only the interaction between the subsystem 
model and the Vehicle object remains. The Vehicle 
class embodies the basic equations of motion. Thus, the 
only subsystem outputs that concern the Vehicle are 
inputs into-the equations of motion — These are mass 


properties J forces, and moments. 


LaSRS++ treats mass properties as a special subsystem 
that is required of all concrete descendents. The Vehi- 
cle class has, as an attribute, a pointer to a MassProper- 
tiesSystem. It uses this pointer directly to retrieve mass 
properties when computing accelerations. Vehicle de- 
rivatives can set this pointer by calling Vehicle: :put- 
Mas sPropertie s Sy stem() . 


Forces and moments, on the other hand, can potentially 
be produced by any subsystem. Typically, more than 
one subsystem contributes. In early LaSRS++ designs, 
retrieving and summing the force and moment contribu- 
tions from the subsystems was done as the definition of 
the abstract method Vehicle: :forcesMoments () . Like the 
operational methods, explicit calls to the subsystem 


^ Mass, center of gravity, and moments of inertia. 


models’ force and moment accessors were placed here. 
If the ProjectModel added or replaced subsystems that 
produced forces and moments, the ProjectModel had to 
copy AircraftModel: :forcesMoments() and make 
modifications. 

The updated design mechanizes the collection of forces 
and moments. The VehicleSystem class defines stan- 
dard methods for derived classes to set a force and a 
moment. These are VehicleSystem: :putForces() and 
VehicleSystem: :putMoments(). The class also provides 
companion accessors that allow the Vehicle object to 
retrieve forces and moments. These are VehicleSys- 
tem: :getForces() and VehicleSystem: :getMoments(). In 
the example, the B 75 7 Aero System communicates the 
aerodynamic forces and moments by adding calls to 
VehicleSystem: :putForces() and VehicleSystem: :put- 
Moments() in its update() method. 

PUTTING IT ALL TOGETHER 

The mechanization of each action has been detailed. 
But, how has the design improved overall aircraft mod- 
eling and project extensions? In earlier versions of 
LaSRS++, aircraft model construction would involve 
the following steps: 

1. The subsystem developer creates the subsystem 
class and its VehicleSystem companion. 

2. The vehicle integration developer creates the Air- 
craftModel class with a shell constructor, destruc- 
tor, operational methods [e.g. doReset()], and 
forcesMoments() . 

3. In the AircraftModel constructor, add code for con- 
structing the VehicleSystem object and for linking 
the VehicleSystem object to its sources. 

4. In each appropriate AircraftModel operational 
method, add code to call the VehicleSystem ob- 
ject’s execution method. 

5. In forcesMoments(), add explicit calls to those 
VehicleSystem objects that produces forces and 
moments. 

6. Combine the code changes for each of the Vehicle- 
System objects and verify placement and order of 
VehicleSystem execution calls in each Aircraft- 
Model operational method. 

Because adding a VehicleSystem to the AircraftModel 
required changes to numerous AircraftModel methods, 
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creating the AircraftModel required significant collabo- 
ration among the subsystem developers and the integra- 
tion developer. Either the subsystem developers made 
their changes directly to the AircraftModel and the inte- 
gration developer merged them together or the integra- 
tion developer added the code for one Vehicle System 
object at a time in consultation with each subsystem 
developer. 

Since each AircraftModel defined their operational 
methods, small variations in the ope rational methods 
did appear between AircraftModels^ jrhese variations 
sometimes caused confusion for developers as they 
moved from one AircraftModel to the next. This confu- 
sion sometimes manifested itself in code defects. 

To extend the AircraftModel in early versions of 
LaSRS++, the Project Model would perform the follow- 
ing steps: 

1. The subsystem developer creates the extended or 
additional subsystem and its VehicleSystem com- 
panion. 

2. The vehicle integration developer creates a Pro- 
jectModel with a shell constructor and destructor. 

3. The integration developer copies the Aircraft- 
Model’s operational methods that will be extended. 
The integration developer also copies forcesMo- 
ments() if applicable. 

4. In the ProjectModel constructor, add code to con- 
struct the new VehicleSystem objects and to link 
those new objects to their sources. 

5. Add code to rewire source inputs for inherited Ve- 
hicleSystem objects if necessary. 

6. In each operational method, add/replace Vehicle- 
System execution calls as appropriate. 

7. In forcesMoments(), add/replace accessors to Ve- 
hicleSystem forces and moments as appropriate. 

8. Combine the code changes for each of the Vehicle- 
System objects and verify placement and order of 
VehicleSystem execution calls in each Project- 
Model operational method. 

Whenever the operational method in the AircraftModel 
changes, the ProjectModel will have to replicate the 

** This was particularly true of the doReset() method. 
Differences in how AircraftModels handled scenario 
definition and initialization were prevalent. 


change. Like the AircraftModel, ProjectModel creation 
required a significant collaborative effort among the 
subsystem developers and integration developer. 

The updated design introduces generic operational code 
that can be moved into the Vehicle class. Figure 4 
shows the code for Vehicle: :doOperateCalc(). The 
aircraft and project teams are freed from writing opera- 
tional code. This provides a very modest code savings 
of -200 LOC for each aircraft and project. The greater 
benefits lie in the standardization of operation and in 
releasing the projects from dup licating the aircraft’s 
operational code. Every aircraft and project now oper- 
ates in the exact same manner. Defects rooted in confu- 
sion about operational differences disappear. Projects 
no longer copy the aircraft’s operational code. There- 
fore, they no longer need to be concerned with migrat- 
ing AircraftModel updates into the ProjectModel. 

The updated design confines the work of defining the 
aircraft or project model to the constructor. Aircraft 
and project models are defined by the composition of 
the VehicleSystem objects that they create. Aircraft- 
Model construction now comprises the following steps: 

1. The subsystem developer creates the subsystem 
class and its VehicleSystem companion. The de- 
veloper codes the connections to input sources in 
the setLinks() method. The developer specifies the 
execution situations by making setUpdateSitua- 
tion() calls in the constructor. If the VehicleSystem 
derivative produces forces, the developer adds put- 
Forces() and putMoments() calls in the update() 
method. 

2. The vehicle integration developer creates the Air- 
craftModel with a constructor and destructor. 

3. In the constructor, the integration developer creates 
each VehicleSystem derivative. Then, the devel- 
oper registers each one in the order of their execu- 
tion by calling Vehicle: :registerVehicleSystem(). 
Afterward, the developer adds a call to Vehi- 
cle ::linkSystems(), which establishes the input con- 
nections for each VehicleSystem object. 

Adding a VehicleSystem object to the AircraftModel 
now requires two lines, a creation line and a registration 
line in the constructor. The vehicle integration devel- 
oper can do this alone. Only the order of registration 
needs to be verified. The updated design has more 
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// This method updates all vehicle systems marked for update in the current situation, 
void Vehicle :: updateSystems (unsigned int situation) 

{ 

list<VehicleSystem*> : : iterator iterator; 

for(iterator = system_list- >begin ( ) ; iterator != system_list- >end ( ) ; iterator++) 

{ 

(*iterator) - >callUpdateNow (static_cast<VehicleSystem : :UpdateSituation> (situation) ) ; 

} 

} 

// The method immediately returns if the vehicle is operating off of a playback file. 

// Otherwise, the method retrieves cockpit inputs. It operates VehicleSystems marked for 
// update prior to summing the forces and moments. It computes the forces, moments, and 
// accelerations. Then, it operates VehicleSystems marked for update after the computation 
// of accelerations, 
void Vehicle :: doOperateCalc ( ) 

{ 

// If a playback file determines the vehicle's behavior, exit, 
if ( getPositionalModelPlayback ( ) - >isPlayback ( ) ) return; 


// If a vehicle limit was hit in an earlier frame, the vehicle must return to 
// RESET mode before it can operate again. 

if (vehicle_limits && vehicle_limits- >limitViolation ( ) ) return; 

processCockpitlnputs ( ) ; // Read cockpit inputs 

updateSystems (VehicleSystem: :DO_OPERATE_FORCE) ; // Calculate forces and moments 
forcesMoments ( ) ; // Sum forces and moments. 

calcAccelO; // Calculate accelerations. 

// Update systems that must operate between acceleration calculation and integration. 
updateSystems (VehicleSystem: : DO_OPERATE_LAST) ; 

} 


Figure 4 Example of Generic Operational Code 


cleanly separated integration from local VehicleSystem 
derivative concerns. Order of execution is the only op- 
erational decision that cannot be made before integra- 
tion because it depends on the set of VehicleSystem 
objects. All other operational decisions can be made 
during the design of the VehicleSystem derivative. In 
the updated design, the subsystem developer captures 
operational decisions in the VehicleSystem derivative 
without a need to coordinate work with other subsystem 
developers. 

The updated design also simplifies ProjectModel crea- 
tion: 

1. The subsystem developer creates the subsystem 
class and its VehicleSystem companion. The de- 
veloper codes the operational decisions as de- 
scribed in first step for the AircraftModel. 

2. The vehicle integration developer creates the Pro- 
jectModel with a constructor and destructor. 

3. In the constructor each VehicleSystem object is 
created. If the object is an addition to the Air- 
craftModel, registerVehicleSystem() is called. If 
the object is intended as a replacement, replace Ve- 


hicle System() is called and the appropriate mutator 
is called to change the replaced VehicleSystem ob- 
ject’s address with that of its replacement. Vehi- 
cle ::linkSystems() is called to establish new con- 
nections and rewire old connections. 

Except for the decision of whether the new VehicleSys- 
tem is an addition or replacement, creation of the Pro- 
jectModel differs little from creation of the Aircraft- 
Model. It is simpler than the old design. It also does 
not require code copying. ProjectModel construction 
also retains the clean separation of integration decisions 
from operational decisions that are local to the Vehicle- 
System derivative. 

FUTURE WORK 

The VehicleSystem design could be expanded further to 
add multi-rate and load balancing features. Multi-rate 
could encompass both super-rating (execute more than 
once per frame) and sub-rating (execute once per inte- 
gral multiple of frames). The VehicleSystem could 
contain attributes that specify its frequency of operation. 
The generic code in the Vehicle class could use this 
information to determine whether and how many times 
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to run a Vehicle System object at each execution event. 
The Vehicle class could also load-balance VehicleSys- 
tem objects across frames if desired. The load- 
balancing algorithm could be incorporated within regis- 
terVehicleSystem() or as a separate step. 

CONCLUSIONS 

Part of the evolution of LaSRS++ has been a focus on 
reducing the amount of duplication required to produce 
aircraft models and project models. LaSRS++ employs 
inheritance to reuse and extend aircraft models for ex- 
periments. Inheritance replaces the use of conditional 
statements or pre-processor directives that pollute the 
aircraft code with project-specific extensions. How- 
ever, “copy and tailor” of operational code remained 
part of the extension method for projects in early 
LaSRS++ designs. The previous VehicleSystem design 
described by Cunningham has been expanded to 
mechanize the five operational decisions for subsystem 
models (i.e. the VehicleSystem objects): invoke the 
correct behavior, execute in the correct order, execute at 
the right event, establish communications, and influence 
vehicle behavior. 4 Defining mechanisms for these ac- 
tions have produced two benefits. 

1. The mechanisms allowed the creation of generic 
operational code in the Vehicle class that is appli- 
cable to the majority of aircraft and project models. 
Developers have been freed from writing opera- 
tional code. Vehicle development has mostly been 
reduced to coding and composing VehicleSystem 
objects. Moreover, the generic code creates a stan- 
dard for vehicle model operation. 

2. Work is more cleanly divided between subsystem 
creation and integration. Of the five operational 
decisions, only order of execution must be estab- 
lished during integration. Subsystem developers 
can encode the other four decisions in the Vehicle- 
System derivative. Thus, a vehicle integration de- 
veloper could compose the aircraft/project model 
from the VehicleSystem objects without knowing 
the details of these objects. The vehicle integration 
developer only needs to know the order of execu- 
tion. Developers do not have to coordinate the 
coding of any single class, in particular the Air- 
craftModel or ProjectModel class. This reduces 


the possibility of errors from conflicting code 
changes. 

In its evolution, the LaSRS++ architecture has reduced 
project creation to “extend and compose”. Projects first 
use inheritance and polymorphism to extend aircraft 
model classes with modified behaviors. Then, the pro- 
jects define themselves through their composition of 
aircraft and project-extended components. 
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